Supporting Conflict Management in Cooperative Design Teams

The design of complex artifacts has increasingly become a cooperative process, with the detection and resolution of conflicts between design agents playing a central role. Effective tools for supporting the conflict management process, however, are still lacking. This paper describes a system called DCSS (the Design Collaboration Support System) developed to meet this challenge in design teams with both human and machine-based agents. Every design agent is provided with an "assistant" that provides domain-independent conflict detection, classification and resolution expertise. The design agents provide the domainspecific expertise needed to instantiate this general expertise, including the rationale for their actions, as a part of their design activities. DCSS has been used successfully to support the cooperative design of Local Area Networks by human and machine-based designers. This paper includes a description of DCSS's underlying model and implementation, examples of its operation, as well as an evaluation of its strengths, weaknesses and potential for future growth. 1 Appears in: Journal of Group Decision Making and Negotiation. Special Issue on the 1992 Distributed AI Workshop. March 1993. Mark Klein Conflict Management 2 1. The Challenge: Supporting Cooperation In Design Groups Design has increasingly become a cooperative endeavor carried out by multiple agents with diverse kinds of expertise. The design of a car, for example, requires experts on potential markets, ease of manufacturability, safety regulations, available means for shipping vehicles, and so on. Many companies are currently studying or implementing approaches to facilitate cooperative design using so-called "concurrent engineering" or "simultaneous engineering" techniques [36]. Conflict resolution is a critical component of the cooperative design process. Different agents, representing different portions (e.g. different product systems) or life cycle stages (e.g. design, manufacture, maintenance and so on) of the design often have different notions concerning what kind of design is best. In one domain studied, roughly 50% of the statements made by a group of collaborating designers involved either the identification or resolution of conflicts [22]. Ineffective management of conflicts can result in greatly increased product costs and reduced quality. In complex artifacts consisting of many interacting systems and/or in artifacts with many different life cycle stages, however, detecting and resolving conflicts effectively can be very difficult. The development of tools and underlying theories for supporting conflict management in cooperative design has lagged, however, behind the growing needs for such work. While other aspects of cooperative activity have been studied in some depth (e.g. [30], [49], [42], [9]) conflict management has been only lightly explored [21]. Work to date has significant limitations; most notably, these systems do not support task-level interaction and embody little or no conflict detection and resolution expertise. The work described here represents the fruition of a three-stage program of research. The first stage involved studying how human designers cooperate to design artifacts [22]. The main lesson of this work was that one can identify general conflict resolution expertise applicable to a wide variety of design conflicts. The second stage involved creating a computational model and associated cooperative design 'shell' that embodies these insights. This shell was instantiated into a system for cooperative Local Area Network (LAN) design consisting of seven machine-based design agents, each with differing areas of design expertise [23]. The third stage involved extending the cooperative design shell to also allow human designers to participate in the design process. In order to do so a model for how human designers and their assistants can effectively interact had to be developed. The extended shell, called DCSS (the Design Collaboration Support System), has been used successfully to support cooperative LAN design with human and machine-based design agents. This work has thus come full circle: insights into human conflict resolution have been embodied into a computer-based system used by human designers. The remainder of this paper is organized as follows. Existing work on computer support for group conflict resolution is reviewed, examining both its contributions and limitations. We then consider the theory underlying DCSS, and look at some examples of its operation. The paper concludes with an evaluation of DCSS and directions for future work. 2. Contributions and Limitations of Existing Work Work relevant to support of group conflict management comes from AI and related fields as well as the social sciences [21]. A large body of work is devoted to analyzing human conflict resolution behavior (see [38] and [8]). This work highlights the importance of conflict in group interactions, but provides few prescriptions for how conflict resolution can Mark Klein Conflict Management 3 be facilitated. In addition, much of this work focuses on issues specific to the psychology of human participants, rather than on the general nature of conflict resolution. There is in addition work on supporting human interaction, including research on group consensus building and group decision support systems (GDSSs). This work can be divided into three major categories: Simple Conferencing Systems: Conferencing or bulletin board systems [19] have proven successful as mediums for the distribution of widely-relevant information but provide too little structure to support effective group decision making. Most recent work in the GDSS literature has accordingly focused on how to best guide the group decision making process. Special Purpose Systems: A number of special-purpose systems have been developed for specific kinds of group decisions. Sarin and Greif [40], for example, have implemented two real-time conference systems including an interactive meeting scheduling system as well as a shared bit-map graphics system. Other systems of this kind include NLS [12] that supports collaborative authoring of structured documents and TOPES [37] for graphically designing building layouts. General-Purpose Systems: General-purpose systems provide one or more widelyapplicable decision techniques (such as voting, agenda-setting, the Delphi technique, or decision tree analysis) for use in a large variety of domains. The Colab project [44] at Xerox PARC uses software tools to support collaboration, brainstorming, evaluation, and linkage between meetings, with the goal of augmenting face-to-face group meetings. Nunamaker et al. [35] have developed systems to support idea generation and analysis in organizational planning based on "brainstorming" techniques proposed in the early 1950's. Chang [6] has developed the Cantata and PCS systems. Cantata supports realtime text exchange among its users, while PCS (the Participant Construct System) deals with knowledge acquisition from a group of users. DeSanctis et al. [10] have have developed a suite of software tools designed to accommodate research into the effect of different research variables (such as meeting structure and group tasks) on the effectiveness of group decision making. Hale et al. [16] have developed EECS, a prototype system for the support of decision making among geographically dispersed hospital chief executive officers. Loy et al. [28] have explored the use of two commonly used decision procedures (nominal group technique and interacting groups) for semistructured group problem solving. Such work provides some structure for interactions among group members, but the conflict detection and resolution expertise is expected to reside in the human participants. This is an inevitable consequence of the level of interaction of the users with the collaboration support system: since the system has at best a very shallow understanding of the contents of the participant's interactions, it can offer relatively little meaningful support. To find work on systems that directly support conflict resolution, we need to turn to AI and related fields such as planning and design. Such work uses expertise encoded in the system itself to detect, understand and resolve conflicts among design participants. This work can be grouped into three categories according to the extent to which conflict resolution expertise is given "first-class" status, i.e., is represented and reasoned with explicitly using formalisms as robust as those used for other kinds of expertise: Development-Time Conflict Resolution: Systems of this type require that potential conflicts be "compiled" out of them by virtue of exhaustive discussions when they are developed [3, 34, 48, 51, 39]. The conflict resolution knowledge utilized by the domain Mark Klein Conflict Management 4 experts is then implicit in the individual conflict resolution decisions made during development. This approach has a number of serious disadvantages. For example, it is very time-consuming to change or add to the existing design agents. In addition, this approach makes the unrealistic assumption that human design agents using a cooperative design system after knowledge-base development will never make conflicting assertions. Knowledge-Poor Run-Time Conflict Resolution: Many of the disadvantages of development-time conflict resolution approaches can be avoided by allowing conflicts to be asserted by the design agents as the system runs, and then resolved by some kind of conflict resolution component. Some examples include approaches using backtracking [46, 47], numerically-weighted constraint relaxation [13, 11] and pieces of specific conflict resolution advice [5, 31]. Such approaches harness little conflict resolution expertise, however, and use highly restrictive formalisms to represent it. General Conflict Resolution: Work in this class come closest to providing conflict resolution expertise with first-class status. It includes implemented systems such as HACKER [45], and BARGAINER [14], as well as proposals for systems [17, 52, 26]. None of this work, however, constitutes a comprehensive theory of conflict resolution. Little conflict resolution knowledge applicable to cooperative conflicts is described, and/or the attempt is made to express this heuristic expertise inappropriately as deductive knowledge. In addition, either few commitments are made concerning how conflict resolution strategies should be represented or reasoned with, or the commitments made are idiosyncratic to a "toy" domain with limited extensibility. Finally, none of these approaches take into account issues particular to distributed contexts (e.g. the need for a shared inter-agent communication language). In general, previous work on conflict management has evolved significantly but falls short of giving conflict resolution expertise first-class status and thus has limited power. In addition, this work has been applied only to machine-based design agents, so issues concerning the interface with human participants have been left unaddressed. In the following section our own approach to supporting conflict resolution among design agents, which we believe avoids the limitations of previous work in this area, is described. 3. DCSS: The Design Collaboration Support System The goal of DCSS is to help human and computational participants of cooperative design teams effectively detect, understand and resolve conflicts among them. DCSS has a distributed architecture consisting of a collection of design agent/assistant pairs (Figure 1). Agents work by refining and critiquing a shared representation of the design, and can be either human or machine-based. Assistants are computer programs that help detect and resolve negative interactions between the actions of the different agents. In the current implementation, human designers work in front of dedicated workstations executing their assistant, while machine-based design agents are independent processes with incorporated assistant code. Agents can be based on different machines, work asynchronously and communicate with each other over a network. The code currently runs on networked Symbolics Lisp Machines and is written in Common Lisp. Mark Klein Conflict Management 5 Assistant Assistant Assistant Shared Product Data Blackboard Network Figure 1: DCSS Architecture Assistants provides three kinds of services to their associated agents: • Conflict detection: Assistants help design agents detect conflicts among each other as early as possible. • Conflict explanation: The causes of a conflict can be difficult to understand given its manifestation. Assistants help agents by suggesting one or more possible causes. • Conflict resolution: Assistants can suggest potential resolutions to conflicts once it has been detected. In the sections below, how assistants provide each of these services is discussed in turn. 3.1. Detecting Conflicts The first service that DCSS assistants provide design agents is support in detecting conflicts among them as early as possible. DCSS supports this in two ways. First, it allows design agents to describe their design actions in terms of a least-committment design model [43] that helps avoid unnecessary conflicts and allows early conflict detection. Second, it provides a range of tools for detecting conflicts once they occur. In the following sections we examine both. 3.1.1. Describing Least-Committment Designs Describing design actions requires an effective interface between agents and their assistants, which implies that the interfaces should be based on a task rather than implementation-level model of the problem domain [15]. Implementation level interfaces, used in many knowledge-based systems, allow the user to interact with the system only in terms of the entities (e.g. rules, facts, ATMS contexts) that the system is implemented in. Task level interfaces, by contrast, allow the user to interact with the system in terms of entities (e.g. resources, components, diagnoses) appropriate to the task being performed. If design agents express their actions using a task-level model, then to the extent that the model is accurate, it Mark Klein Conflict Management 6 allows these agents to communicate in a domain-natural but computer-interpretable way. In the paragraphs below we briefly describe DCSS's task-level model of cooperative design as well as the interface to human design agents based on this model. For a fuller description see [25]. In DCSS, physical artifacts are viewed as collections of modules, which can represent entire systems, subsystems or their components, each with characteristic attributes, whose interfaces (with their own attributes) are connected by connections of a given type. The resources used by a module (e.g. cost, weight) are represented using a special class of attribute (Figure 2). Interface Attributes Module Attributes Module Attributes Interface Attributes